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© Controlllngtheexecution of host computer application programs throughasecond computer. 
(*2) Method and apparatus for executing a computer applica- 
tion program In a host computer under the control of a 
second computer located at a workstation include the steps 
of translating selected portions of the host computer's 
presentation information into functionally equivalent user- 
oriented presentation information for use in the second com- 
puter, and translating a user's responses to the user-oriented 
presentation information at the second computer Into re- 
sponse information for use in the host computer to interact 
with the application program. 
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CONTROLLING THE* EXECUTION OF HOST COMPUTER APPLICATION 

PROGRAMS THROUGH A SECOND COMPUTER 

DESCRIPTION 

This invention relates to the execution of computer 
application programs in a host computer under the control 
of a second computer, which can be a less powerful 
c orr.pu t & r • 

There is a need in the data processing field for a 
single product configuration capable of addressing the 
following requirements in the computer industry: 

1. The ability to develop and operate "user friendly" 
interfaces which, by providing, added functions! capability 
(such as integration of application data), result in 

. computers which have a high degree of consistency and 
ease of operation through the use of techniques such as 
high function representations in the form of graphic- 
icons and other graphics, and which will be relatively 
easy for a user to learn, preferably ii¥ an intuitive way. 

2. The ability for new computer environments to 
operate existing software packages, without modifications 
to those packages, and to retain the benefits currently 
found for those applications which run in a multiuser, 
multitasking, centralized computer which provides a high 
degree of storage capacity, processing capacity and 
information management services. 

3. A method for transferring and exchanging data 
among various different applications and host computers. 

.Although there are various approaches which provide • 
partial solutions to these problems, presently there is 
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1 no set of' products designed specifically to address all 

2 of theBe requirements. The current approaches fall into 

3 two categories: 

4 1. Move the application functionality to a cost 

5 effective, user- friendly, computer workstation environ- 
6* ment which provides both the hardware and software tools 

7 and technology to add the functionality of a user-friendly 

8 interface to the application. For most business application 

9 uses, this computer workstation environment is obtained 
10 through the use of the class of microcomputers known as 
21 personal computers. 

12 Although this approach has been used to effectively 

13 provide the benefit of the user-friendly interface, 

14 moving the application functionality involves various 

15 amount of reengineering and rewriting in order to move, 

16 or "port", the application to this computer workstation 

17 environment. The costs -of such reprogramming often makes 

18 this approach undesirable. 

19 In addition, if the entire application software and 
data files are moved to this workstation environment, the 
workstation capacty, due in part -to its cost effectiveness, 
often becomes a problem and the processing capacity required 
to provide the user- friendly interface functions plus the 
application processing is often beyond the capabilities 
of this werkfitation environment. In addition, the micro- 
processor technologies used in these workstations are 
often limited, in the amount of storage which the work- 
station is capable of accessing. Even where th,e storage 
capacity is available in this workstation environment, 
the problems of distributed information management often 
outweigh the advantages obtained. 

A hybrid approach allows the application software to 
operate in a secondary computer workstation but the data 
files remain in the multiuser, multitasking, centralized . 
computer,. This approach has the advantage of providing 
the centralized information management services and the 
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1 user-friendly interface while retaining, and even increasin 

2 the capacity of' the multiuser, multitasking, central 

3 computer. Since this approach involves a secondary-to-host 

4 computer link, accessing data over that link often presents 

5 severe performance limitations. The costs of moving the 

6 'application remain a disadvantage... In addition, the 

7 processing capacity required to provide the user- friendly 
6 interface functions plus the application processing 

9 is often beyond the capabilities of this workstation 

10 environment. 

11 2. Add the user-friendly interface functionality 

12 to a multiuser, multitasking, centralized computer which 

13 provides a high degree of storage capacity, processing 

14 capacity, information management services. 

15 Attempts to program the centralized computer to 

16 perform the user- friendly functons are usually limited by 

17 a lack of hardware, software tools and technology to 

18 provide such functions. 

19 The hybrid .approach involves the use of sn intelligent 

20 terminal or computer workstation in conjunction with the 

21 "programming of the central computer. In this approach, 

22 the application in the central computer is programmed to 
23- direct the workstation to perform many of the user-friencly 

24 functions at the appropriate time during the execution of 

25 the application. Adding the user-friendly interface 

26 functionality involves the various amounts of reengineering 

27 and rewriting of the application. The costs of such 

23 ^programming often makes this approach undesirable, in 

29 addition, such an approach, to provide the maximum benefit, 

3 0 would obsolete the existing terminals used with the 

31 application. 

32 The present invention accordingly uses a secondary 
23 computer communicating with an existing multiuser, 

34 multitasking, high capacity, centralized computer to 

35 provide the tools ______ • 

36 
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\ and technology which allows the development and operation 

2 of adaptive, user-friendly interfaces to existing applica- 

3 tion software packages operating in that centralized 

4 computer. The invention allows the secondary computer to 

5 function as' a distributed processor, operating in conjunc- 

6 'tion with the central computer to perform the functions 

7 required to provide a user- friendly interface. 

8 The invention also provides a machine- independent, 

9 information-exchange environment and subsequent method for 
10 transferring and exchanging data among applications and 
21 hosts. Furtheremore, the invention provides the added 

12 functionality without requiring the application software 

13 in the centralized computer to be changed in any way. 

14 Utilizing this invention presents an environment 
which provides a standardized style and manner by which 
the user interacts with various, different applications. 

17 The present invention distributes the functions of access- 

18 ing and interacting with one or more host applications 

19 and providing a user- friendly interface for each applica- 

20 tion, such that new or existing full featured business 
applications can run unencumbered in the more powerful 
host computer while the majority of the power of the 
secondary computer can be used to present the user with a 
state-of-the-art, user-friendly interface to the applica- 
tion^). Thus, many of the performance limitations of a 
secondary computer are avoided. 

The secondary computer, which can be described as a 
very intelligent workstation, changes the user's environ- 
ment from one in which a user must adapt to a fixed 
interface for each application and a fixed method of v 
operating the secondary computer (or alternately, a 
present-day computer terminal) to one in which the user 
defines the way he wishes to interface to the application 
even though the application interface in the actual host 
application regains fixed. As a result of this invention. 
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I a™," \ S -"° n£ed t0 m ° dify tte VaSt lib ""« <* bMi«., 

S S ° ftKare t0 Pr ° V " e sucl > » interface 
3 Transitions ln conditions accomplish that 

6 f Since v 6 arChlt6 «"" <* this Lent o [ 

6 Since the application remains, in the host comouter 

7 and only a relatively emaU 6et of translation innruT 
« tlons. called an application interface module «n , „ ' 

9 t h6 *r ded to be executed by **• ■•«-«* co-u t ;; y 

10 the problems associated with the relatively sr-n " 

11 oi the secondary computer are overcome. Zo Tn 

12 the AIM and data that has; been used or chanced bv t" 5 ' 

13 user needs- to be moved from or to the host syftL " 

14 -ance delays typical of more conventional lyllZs 'Ire 

15 overcome. systems are 

16 Additionally, since the environment create- bv the 

17 invention fully supports multi ple sessions in " of 

18 applications running on a , single host or on epar " 
1. hosts, and since the environment translates an a" £. 

20 tlons user interface operations such that, while b" 

21 operated on by way of the secondary comber, ey T 

22 "aye a common data and interaction form. interne L 

23 integration of information between any aopiicati, t 

24 a readily available facility to the IT Z Zi^ 
" f r , 9rapMc "Nation derived from the host J 

26 tion but created in the secondary computer can be d 

27 to the information that is a part of the mlictt ?* 

28 the host system. °"' 

29 ., That is ' tte ""naary computer' presents the s=,„ 

so familiar user friendly interface to the user for a Vi t, v " 

31 of application programs to be' run, thus eliminati,, ^1 

32 . need for the user to learn the often complicated £Ut 

33 of interfacing with a variety of different a C olicat<on 

34 programs, while still making available to the'user the 

35 benefits of these application programs. Additionally ' 
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this solution avoids the complexity and maintenance 
costs of distributed information management. 

A multiuser multitasking host computer employing 
the present invention and using the secondary computer 
as a terminal can continue to be a node in a networking 
environment, 'should the user's needs require a network. 

Thus it will be .evident that the present invention 
can be embodied so as to meet the requirements stated 
in 1,2 and 3 above*. 

The invention is further explained below, by way 
'of illustration, with reference to the accompanying 
drawings, in which; 

Fig« 1 illustrates an architecture overview of a 
system embodying the present invention} 

Figs* 2a, 2b and 2c, when placed side by side, 
illustrate the general flow of information through the 
present system; 

Fig * 3 illustrates the input stream processing in 
the system of the invention; 

Figso 4 and 5 illustrate display processing and 
display updating, respectively; 

Fig 0 6 illustrates , keystroke processing; 

Fig 0 7 illustrates mouse processing; 

Figs* 8 and 9 show AIM initialization and signal 
processing, respectively; 

Fig. 10 illustrates the rule processing detail; 

and 

Figs. 11 and 12 are examples of Rule Sequence and 
Rule Execution tables, respectively. 

The illustrated embodiment of the present 
invention will be described by first providing an 
overview of the architecture thereof o 
Architecture Overview 

The workstation of the present invention connects 
to a host computer in the usual manner* As shown in 
Fig- 1 9 
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1 the user communicates with a host application prooram in 

2 the host computer 11 through the present workstation 

3 using a keyboard, a display screen 13, and optionally a 

4 mouse. Information is presented on the screen 13 through 

5 a set of icons, secondary computer-style windows and 

6 'pull-down menus. 
7 

• 8 The host's "screen" information and the user's 

9 reactions to that information may be modified by me^ns 

10 of a set of translation functions which are defined by 

11 the application interface modules (AIM) . since the /IH 

12 functions are executed by the workstation, the load on 

13 the host processor 11 may be. reduced. 
•14 

15 Run-time System and Tonic; 
16 

17 The run-time system provides the interface between 

18 the secondary computer native operating svstem and the 

19 various modules and tools operable within the environment 

20 of the invention. The operating run-time systen sucr^ies 

21 many generalized functions and tools which are used 

22 during the development and execution of an AIM. 
. 23 

24 The central event/time monitor, a major portion o^ 

25 which may be supplied by the native operating system for 

26 the secondary computer, is the focal controlling" fur.ctio- 

27 within the present operating run-time system. The central 

28 event/time monitor buffers the interrupt-driven events'"" 

29 (e.g., arriving characters, keyboard end mouse operations) 

30 and performs the distribution of those events to the 

31 .time-driven operations (e.g., display screen updating) 

32 and to the event-driven operaticr.s (e.g., AIM processing) . 

33 In addition, the central event/time monitor crovides the 

34 "process" distribution (i.e., which AIM is to be er.oloyed) 

35 and the prioritization services. 
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1 Communication Functions 
2 

3 The host computer 11 communicates with the workstation 

4 through the comm(unication) functions element 16. The 

5 input and output communication functions provide the 

6 interface between the terminal emulator 17 and the host 11. 

7 These functions provide the required secondary-to-host 

8 link-level protocol (e.g., packetizing/depacketizing, 

9 error control, flow control, etc.) and the multiplexor/ 
10 demultiplexer switching function necessary to support 
al multiple, concurrent, virtual terminal sessions. 

12..-" 

j 3 In the input mode, coipunications functions element 16 

14 receives the data stream which has been conditioned by 

15 host 11 according to the communications protocol and, 

16 after performing the necessary operations required to 

17 remove the communications protocol from the data stream, 

18 passes the data stream to terminal emulator 17. In the 
output mode, communication functions element 16 accepts 
characters from terminal emulator 17, conditions the data 
stream according the ccmmunications protocol, and transmits 
the data to host 11. 
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A different set of communications functions is 
usually required for each class of communication link 
hardware and/or protocol supported (e.g.. F.S-222/C, 
Ethernet, Apple-Bus, etc.)'. Furthermore, since communi- 
cation functions must be supported by host 11, the set of 
communication functions for any given secondary-to-hcst 
connection is usually defined. at the time of physical 
connection and remains rela-ively fixed. 



A given set of coatuniceticns functions may support 
„, a set of link-ievel protocols and a set of multiplexing/ . 
demultiplexing (Mux/DeMux) protocols. A different Kux/DeMux 
is usually required for each class of host protocol 
supported (e.g., 3270 Bisynchronous (BSC) and System 
Network Architecture (SUA), etc.). • 
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1 Terminal Emulator 

2 . Terminal emulator 17 performs two sets of translations 

3 The incoming, terminal-dependent data is trans- 

4 • lated to a secondary environment-dependent, internal 

5 f ("universal") representation for use by the remainder 

6 of the system. 

7 The outgoing "universal" (secondary computer- 

8 dependent) data is translated to a terminal-dependent 

9 data stream for use by the host application. 
10 

11 / Terminal emulator 17 receives the incoming data 

12 -stream originally -generated by the host application 

13 program from communcations functions 16. The emulator's 

14 outgoing data stream is generated by mouse and keyboard 

15 operations after the events have been processed by the 
15 keyboard and mouse processor 18. 

17 

18 Since the incoming data stream is translated to the 

19 internal representation used vithin the secondary computer, 

20 a library of control functions is accessible to perform 

21 the various terminal functions. Furthermore, once a 

22 routine is developed to perform, for example, a screen 

23 control operation, that routine may be used in a "mix and 

24 match" manner during the development of other terminal 

25 emulators. The present invention environment provides a 

26 library of common screen control functions to choose 

27 from. In essence, the terminal emulator presents a 
23 predefined, terminal-independent interface to the aim. 

29 Terminal emulator 17 also performs "local" operations 

30 normally present in the terminal being emulated (e.g., 

31 block mode transmission, programmable function key cap- 

32 abilities, etc.). 

33 

34 Virtual Terminal Buffer 

35 . The virtual terminal buffer 19 contains the host's 

36 screen information. Since all information contained 

37 
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1 within the normal host screen is represented in a consis- 

2 tent, internal format, the^ virtual terminal buffer is the 

3 reference point for interaction with the host application. 

4 

5 Application Interface Module (AIM) 

6 ' The AIM, represented symbolically as 21 in Fig. 1, 

7 is the mechanism which provides the unique, host applica- 

8 tion-dependent working environment within the secondary 

c computer workstation. The AIM is where the user interface 
10 characteristics relative to the host's application are 
H implemented- In essence, the AIM provides two sets of 
12 .translations: •. 

13 * The host's "screen" presentation is translated 

14 to a functionally equivalent, user-oriented presen- 

15 tation of the information. 

16 The user's actions, resulting from the user's 

17 view of the' host application program as presented at 
the secondary computer, are translated to the appro- 
priate "keystrokes" required by the host application. 
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This has the advantage that the user at the workstation 
employing the AIMs need not have any detailed knowledge 
of, or training on, the host computer to be able to cause 
execution of the selected application program on the host 
computer under the control of the user at the workstation. 

26 The user may interact at the workstation using the user 

27 friendly interface thereof, including icons and other 
features of this interface, with which he is familiar. 
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The AIM logically ccr.sists of two major components, 
a host data stream processor 22 and the various ncuse and 
keyboard processors 18. 

AIM Input Data Processor . 

The host data stream processor 22 analyses and 
processes the data stream from hcst 11 relative to the 
virtual terminal buffer 19. It is only through this 
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1 analysis that the host application program can be -unde- 

2 stood", wost translations of the host's screws are" 

3 performed by the host data stream processor (- c rea- 

4 ranging display areas and changing character fonts' before 

5 presentation to the user). 
6 

7 Mouse and Keyboard Processors 

8 The mouse and keyboard processors 18 aralyze and 

9 process the data stream from the mouse and .ke'yboard 

10 relative to the virtual window buffer. It is only th>-ouch 

11 this analysis that the user can be -understood" and 

12 related back to the host "screen". Most translations of 

13 the user's actions are performed by mouse and Wboard 

14 processors 18 (e.g., sending characters as a result 0 ' 

15 pull-down menus, cursor positioning by pointing, etc.)". 

17 Virtual Window Manager • 
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The virtual window manager 26 performs most of 

20 common but complex operations necessary to jr— e t-e 

21 presentation of information from the virtual terminal 

22 buffer 19 on screen 13. The "normal" secondary coir-out- 

23 window environment is transparently available to the'l^t 

24 application through the AIM to present workstation discley 

25 (e.g., KELP information, status queries, etc.). j n * 

26 addition, virtual window manager 26 provides much of th» 

27 mouse-event processing (e.g., cursor movement bv cointinq 

28 area selection, etc.) and supplies the functions recWd 
2 o to relate the user's presentation to the host's pres"ent=- 

30 tion (ie., the mapping of the virtual" window buffer to" 

31 the virtual terminal buffer). 
32 

33 Virtual Window Buffer 

34 The virtual window buffer 27 contains the user's 

35 view of the host's application "screen". since t*e 

36 information to be displayed to the user is reoresented in 

37 * consistent, internal format, virtual window buffer 27 
28 " the reference point for interaction with the user 
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1 AIM Development Process 

2 The AIM development process is primarily one of 

3 table specification and editing. A significant percentage 

4 of the work is in the characterization of the interface. 

5 Once the interface has been characterized, the various 

6 'components of the interface may be specified. Given a 

7 "template" AIM, known as a terminal emulator or "pass- 

8 through" AIM, the "developer" first creates the various 
o types of secondary computer resources (i.e., tables and 

10 functions) required by AIM (e.g. , menus, dialogs, windows.) 

11 The "empty" predefined AIM resources', called Rule Tables, 

12 -are edited to ••.•program" the application-specific interface 

13 operations. Once the Rule Tables have been completed, 

14 the AIM resources may be checked, parsed, optimized, 

15 tokenized and linked by the AIM generator. The resulting 

16 AIM may be installed oh the host using the present func- 

17 tions of the secondary computer. 
18 

19 OVERVIEW OF OPERATIONS 
20 

21 The discussion below follows seme hcst-cenerated 

22 data (a "screen- full", for example), through the present 

23 system, describing the operations resulting frcm a user's 

24 response to this data, and the data sent back to the host 

25 as a result of the AIH's translation of the user's actions. 

26 This portion of the discussion does not consider the 

27 detailed contributions of the workstation's native cperat- 

2 8 ing system or the run-time environment. Instead, the 

29 discussion' assumes that the host connection and log-in 
-o procedures have been performed, that the host application 
3, has been brought into play and that the appropriate AIM 

32 has been initialized in the workstation. The AIM consists 

33 of various resources which direct the operation of the 

34 run- tine system. 
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1 AIM Initialization 

2 . Reference may now be had to Figs. 2a, 2b and 2c 

3 which, when laid side by side, show an overview of th* 

4 system operation. When an AIM is loaded into the run-t<ne 
' f system, initialization processor 8 (Fig. 2a) performs t*e 

functions required to "get an AIM started" (e.g. create 
a window, etc.). In short, the AIM initialization processor 
8 sets the beginning environment for the AIM 
9 

10 AIM Sicmal Processing 

11 / % At various times during the execution of an AIM 
^--different events may occur which are not otherwise handled 

13 during the normal flow of events. Such events may be 

14 defined as signals to be processed by the AIM signal ' 

15 processing subsystem. The signal processor 9 per f cms 

16 the functions required to respond to the various stimuli 

17 defined as signals (e.g., events such as activate window 
• 18 or messages such as "physical host connection lost" 

19 etc.). 
20 

21 Host Data Stream Input. 

22 The "screenful of data" generated by the host enters 

23 the workstation by way of the host data stream incut 

24 subsystem. The host data stream input subsystem contains 

25 both the link-level communication protocol driver 31 

26 (Fig- 2b) and demultiplexer functions 32. Generally, t.V 

27 native environment I/O port driver 33 accepts the incoming, 

28 host-originated characters and activates the link-level 

29 communication protocol driver 31 which, in turn, activates 

30 demultiplexer 32. Link-level protocol driver 31 remove * 

31 the protocol information from the input data stream and" 

32 when it has been stripped of all its protocol overhead,' 

33 it is passed to demultiplexer 32. 

34 • . 

35 The multiplexor/deaultiplexor functions supports the' 

36 concurrent operation of multiple, virtual circuits over a 
37 . single physical connection. The demultiplexer removes 
38 



023767H 

-14- 

1 the multiplexing information from, the data stream, then 

2 places the data in the input queue which consists of a 

3 first in-first out (FIFO) input buffer 34 (Fig. 2c) 

4 logically attached to the AIM associated with that virtual 

5 circuit. The data in the FIFO 34 is identical to that 
6' which was generated by the host application, and FIFO 34 
7 provides buffering for the input terminal emulator 17a. 

8 

o Input Data Stream Processing 

10 Once the data has been entered into the workstation, 

11 the job of translation can begin. Still referring to 

12 Fig. 2c, the input data stream processing subsystem 
consists of the terminal emulator 17a, virtual terminal 
buffer 19, AIM input stream processor 20, virtual window 
manager 26, and virtual window buffer 27 functions. 
Terminal emulator 17a translates the terminal-specific 
data into a workstation representation, buffers the 
information in virtual terminal buffer 19, then notifies 
AIM input data processor 20 of the arriving characters. 
AIM input data processor 20 performs any required proces- 
sing, then passes the characters to virtual window man- 
ager 26. Virtual window manager 26 maintains virtual 
window buffer 27 in a manner which allows optical updating 
of the workstation screen display. Virtual window buffer 27 
provides buffering for the bit map update manager 30 
which is periodically activated to update the workstation 

27 display screen. 
28 

Display Frocessinq and Update • 

The display processing subsystem manages the bit-map 
update functions used to generate the workstation display. 
Based upon the elapsed tir.e, the bit map update manager 30 
activates the native bit ma? update routines. The display 
update subsystem performs the actual bit map update of 
the workstation display. 
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1 Keystroke Processing 

3 the ^\ kB T r T Pr ° CeSSin9 SUbs ^ st - (Fig- 2a, performs 

3 the AL-l keyboard processor portion of the mouse end key- 

4 board processor. 18 functions. The keystroke processing " 

5 subsystem contains the physical keyboard processor 23 ' 

6 menu key processor 24, AIH keystroke processor 25, and 

7 output terminal emulator 17b functions. 
8 

S Events from the keyboard activate physical kevboard 

10 processor 23 which, in turn, activates menu key processor 2. 

11 If the keystroke from the keyboard is eouivalent to a 

12 menu selection, control is passed to AIM menu proc-sc- -6 

13 (Fag. 2b). other keystrokes are passed to AIM keystroke" 

14 processor 25, then to output terminal emulator 17b 

15 Emulator 17b, which may also receive keystrokes from the 

16 AIM menu and point processors 36, 37, places the character 

17 an an output FIFO 38. - 
18 

19 Host Data Stream Output 

20 The host data stream output subsystem consists of 

21 multiplexor 39 (Fig. 2b) and output link-level ccroaunica- 

22 tion protocol driver 41 functions. The characters to b- 

23 output are taken from output FIFO 38 and processed by 

24 multiplexor 39 and the link-level communication protocol 

25 driver 41. When the character stream has been condi- 

26 tioned, i.e., its multiplexing and protocol envelope ha^e 

27 been added, the I/O port driver 33 from the native' enviv cn 

28 ment is used to transmit the characters at the h-r-wa-e * 
2? I/O port level. Output FIFO 3S provides buffering from 
3D output terminal emulator -17b until multiplexor 3? - 

2i activated to process the characters. 

32 

33 DETAILS OF 0?£3A7ICM 

35 I"put Stream Processing 

26 Referring to Fig. 3... the central event/time monitor 10 

37 vithan the operating rur.-tir.e system maintains the AIM 
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1 control tables 28. It is through these tables that th- 

2 central event/time monitor is able to determine which 

3 input FIFO is attached to which virtual circuit. 
4 

5 When the host data stream arrives at the native 

6 environment port, an interrupt is generated which passes 

7 control to the port driver routines. The driver routines 

8 buffer the arriving characters and communicate with the 
c communication driver. The cor.muni cation driver, based 

10 upon a specified minimum nurier of characters in t>-e 
H input FIFO 34, gets the buffered characters from the 

12 appropriate port driver. After calling the port driver ' 

13 to get a set of characters from the driver's input buffer, 

14 driver 33 performs the required buffering, error-checking 

15 error correction and/or transmission procedures, where 

16 required. The communication driver, based upon a specified 

17 maximum r.umbtx of characters in input FIFO 34, mav also 

18 call the port driver to perform flow control. When these 
I? operations are completed, the cc.Tjnunication driver passes 
2G the characters to demultiplexer 32. Der.uiticievc-r 22 

21 places the characters into the sectic.n(s) of the inrut 

22 FIFO depending upon the virtual circuit to which the 

23 characters belong. V.'hen complete, control is returned to 
2- the central event Wr.i tor 10. 

25 

25 Eased upon an elapsed tine function, central event/ 

27 time monitor 10 controls the passing characters to input 

28 -.erminal emulator 17a. Monitor 10 is also responsible 
2? for determining and setting the priority for the distri- 
20 buticri °f the host data stream characters. Termir.cl 
31 emulator 17a translates the terminal-specific data ir.to 
22 the "universal" representation used in the present inven- 
tion, buffers the information in virtual terminal buffer 19, 
then notifies aim input data processor 20 cf the arriving. 

5 characters. Terminal emulator 17a also maintains the 

6 data structures within virtual terminal buffer 19. Input 

7 data processor 20 performs any rule-directed processing, 
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1 then passes the characters to virtual window manager 26. 

2 Virtual window manager 26 maintains the virtual window 

3 buffer 27 in a manner which allows optimal updating of 

4 the workstation screen display. Virtual window buffer 27 

5 provides buffering until the bit map update manager (Fig. 

6 4) is activated to update the display screen. The hc = t 

7 data stream input subsystem allows the system to inject a 

8 "pseudo host" data stream into the processing cycle bv 

9 way of the virtual data stream input port 29. 
10 

11 To perform its functions, terminal emulator 17a 

12 follows the program provided by the sequence and execu- 

13 tion tables within the terminal emulator rules. The 

14 result is the updated contents of the virtual terminal 

15 buffer (for both host and local operations) and, where 

16 necessary, activation of the AIM input data processor. 
17 

IB When the terminal emulator retrieves a character 

19 from the input FIFO, the characters are (host application) 

20 terminal-specific and, generally, of two types: 

21 1. Data characters which are translated to their 

22 ASCII representation before being stored in 

23 virtual terminal buffer 19. 

24 

25 2. Control characters which indicate ter.-inal 

26 control operations and are translated to a 

27 universal representation. In this application, 

28 the term "universal" is used to indicate a 

29 predefined, internal representation. used by the 

30 workstation software. The universal represen- 

31 tation has various fonr.s. The control characters 

32 it. ay be translated to: 
33 

34 A set of -pointers to a structure within 

35 the virtual terminal buffer (e.g., the 

36 general result of explicit cursor adcress- 

37 ing cc.Tjr.ancs ) . 

36 • 
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1 A set of bits within the virtual terminal 

2 buffer (e.g., the result of. explicit 

3 character attribute commands such as set 

4 intensity, underline, reverse video, 

5 etc. ) . 

6 

7 The presence or absence of data at a given 

8 position within the virtual terminal 

9 buffer (e.g. , the result of explicit 

10 screen operations such as clear to end of 

11 line, etc.). 

12 

13 Combinations of the above as a result of 

14 explicit control sequences (e.g., clear 

15 - screen, which normally repositions the 

16 cursor) or, more usually, as the result of 

17 implicit, control operations (e.g., most 
23 operations involving data characters cause 
2o a repositioning of the cursor and will 
2q often imply a change to the associated 

22 character attributes). 

22 

23 After the virtual terminal buffer 19 has been updated, 
2 a AIM input data processor 20 is called. The call to 

25 the input data processor specifies the operation and 

26 the character (s) affected by the operation. 

27 

_ Virtual terminal buffer 19 contains a terminal- _ 

*t o 

OQ independent version of the host's application screen. 
The information is the result of characters which 

31 have arrived from the host and have been processed 

32 by the various components of the communi cation 

^ module and input terminal emulator 17s. The buffer 19 

^ A contains, in its universal representation, all the . 

~ 5 host's screen information and is the reference point 
for interaction with the host application and for 

JO 

„ local terminal emulation functions. 
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AIM input data processor 20 is the portion of the 
AIM which performs the majority of the screen trans- 
lations from what the host application generates to 
that t which . the user views and interacts with. 
Processor 20 receives information from the terminal 
emulator 17a which indicates the operation performed 
by emulator 17a and the characters ) affected by the 
operation. Processor 20, after completing its 
operations, passes the characters and operations to 
virtual window manager 26. 

Virtual window manager 26 maintains the data struc- 
tures within virtual window buffer 27. Khen manager 
is passed a character by processor 20, the characters 
are terminal-independent and, generally, are of two 
types, as indicated above for terminal emulator 17. 

Data characters indicate displayable characters 
to be stored in the virtual window buffer. 

Control characters indicate screen or window 
control operations used in universal represen- 
tation. These control characters are of the 
type discussed above in connection with terminal 
emulator 17. 

Virtual window buffer 27 contains the user's view of 
the host's application screen. .The information is 
the result of buffer 27 infomation translated by 
processor 20. Buffer 27 is the reference point for 
interaction with the user fcr both host-orier.ted and 
for local emulator functions. The buffer infcrn.aticn 
is accessed by the bit map update to present the 
user's screen display. 



0237671 



-20- 

1 Display Processing 

2 . The display processing subsystem (Fig. 4) manages 

3 .the bit map update functions used to generate the display. 

4 Based upon the elapsed time, the central event/time 

5 monitor 10 activates the bit map update manager 30 which, 

6 in turn, activates the native bit map update routines as 

7 shown in Fig. 5, display update. 
8 

9 Display Update 

10 The display update subsystem performs the bit map 

H update of the workstation display. Based upon the elapsed 

12 time, the central event/time monitor 10 activates the 

13 native environment bit map update routines 43. 

15 ' The central event/time monitor, based upon the 

16 elapsed time and the current state of virtual window 

17 buffer 27, periodically activates the native environment 

18 bit map update 43. The native environment bit map update 

19 is part of the native operating system and is used to 
generate the user's display. The update uses virtual 
window buffer 27 and the display font 53 to generate the 

2 2 display. Display fonts 53 are the tables used by the 

23 native environment bit map update to generate the various 
. 2 4 displayable characters. 

25 

26 Keystroke Processing 

27 The keystroke processing subsystem (Fig. 6) performs 



20 
21 



28 



the AIM keyboard processor portion of the mouse and 

2 9 keyboard processor functions identified in Fig. 1. The 

3C keystroke processing subsystem contains the physical 

31 keyboard processor 23, menu key processor 24, AIM keystroke 

3 n processor 25 and output terminal emulator functions, 

3 I Based upon events frcm the keyboard, the central . event/time 

3 ^ monitor 10 activates the physical keyboard processor 23 . 

35 which, in turn, activates menu key processor 24. If the 

36 keystroke from the keyboard is equivalent to a menu 

37 selection, control is passed to the AIM menu processor 36 



23 



1 

2 
3 
4 
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(Figure 7). Other keystrokes are passed to aim keystroke 
processor 25, then to output terminal emulator L 
Terminal emulator 17b ( which may also receive keystroke 
from the AIM menu and point processors 36, 57, passes t-e 
5 host-destined characters to the. output FIFO 38 

6 

7 Central event/time monitor 10, in respc.se to keyboard 

8 interrupts, generates keyboard data-available events and 

9 passes the raw keystroke ; data to physical keyboard pro- 

10 cessor 23. As mentioned above, AIM control table 29 

11 contains the data structures required to switch data and 

12 -operations among the AIMS. Physical keyboard p r0 cec SO r 23 

13 performs the mapping of the currently-installed, physical 

14 raw keyboardcbaracter representation and layout to the 

15 logical, keyboard character representation and layout 

16 Accessor 23 follows the program provided by the seouen-e 

17 and execution tables within the physical keyboard rules 

18 Physical keyboard processing rules 47 provide the Pro - r -'- 

19 mng for the physical keyboard translations. virtu.V'"" 

20 ^.y S t roke iRput port 48 prov . des an . ntern£i lnte 

21 slT* 7 ° ther ^ ° f SySt£m "* ^ ect c *aracter 

22 stream information (e.g., the emulator when operating in 

23 block mode). * 
•24 

25 Menu key processor 24 is responsible for recoon^irg 

2 6 command key sequences which are equivalent to menu 'choices 

2 7 selected from a pull-down menu by way of a , 0 use operatic" 

28 When a menu-equivalent keystroke combination is entered 

29 H r :r S ° r 24 9enerateS a " eVent ^^alent to' 

30 that which the mouse event decoder 40 (Fie 7 ) wou- 

32 selection processor 36. AIM keystroke processor 25 < s 

23 the portion of the AIM which performs the majority of the 

34 user translations from what the user generates to th-t 

3 £ which the host application receives and interacts with 

36 Processor 25 is passed keystrokes generated by the uc er 

27 through keyboard or mouse operations. The keystroke 
38 
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1 processor passes the characters to the output emulator 

2 17b. To perform its functions, processor 25 follows the 

3 program provided by the sequence and execution 4 tables 

4 within the AIM keyboard rules. 

# 

5 

6 ' Output terminal emulator 17b passes the data stream 

7 generated by both the AIM keystroke and the AIM menu and 

8 jioint "processors 25, 36, 37 (resulting from the user's 

c actions) to the output FIFO 38. The emulator also performs 

10 the local terminal operations defined for that terminal 

11 type. To perform its functions, emulator 17b follows the 

12 program provided by the sequence and execution tables 

13 vithin the emulator rules. 
14 

15 When emulator 17b is passed a character by either 

16 the AIM keystroke processor or the AIM menu and point 
!7 processor, the characters are terminal- independent and, 
16 generally, of two types. 



9 



20 Data characters indicate data and are translated to 

21 their terminal-specific representation before 

22 being passed to the FIFO 38. 



23 
24 
25 
26 

27 Mouse Processing 



32 
33 
34 
35 
36 
37 



Control characters trigger the "local", terminal 
control operations within the emulator. 



The mouse processing subsystem (Fig. 7) performs the 
mouse processor portion of the mouse and keyboard processor 
functions identified in Fig. 1. The mouse processing 



28 

29 
30 

31 subsystem contains a mouse event decoder 40, region 
selector 42, scroll processor 45, AIM point processor 37 
and AIM menu selection processor function 36. Eased upon 
events from mouse operations, central event/time monitor 10 
activates mouse event decoder 40. Mouse event decoder 40, 
based upon the type of mouse operations ) , activates one 
of the four modules which process mouse operations. 
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1 Region selector 42 causes the identification of a 

2 workstation screen region, both visually, by displaying, 

3 for example, in reverse video for the user, and through e 

4 set of coordinates for the workstation software. Selected 

5 regions may then be processed by subsequent operations 

6 such as cut, copy, etc. When regions are selected which 

7 are beyond the boundaries of the current virtual window 
e buffer, region selector 42 activates scroll processor 45 
9 to perform the scrolling functions. 

10 

11 Scroll processor 45 handles the scrolling of the 

12 screen display. Scrolling actions are either local, 

13 i.e., within the boundaries of the virtual window buffer, 

14 or out of bounds of the virtual window buffer. Scrolling 

15 beyond the current contents of the virtual window buffer 

16 causes the host to perform the scrolling within the 

17 application. Using the AIM-supplied scrolling rules, 

18 scroll processor 45 is able to interact with the host 
tc application, independent of the AIK's involvement, to 
20 cause the host to scroll. 

21 

22 AIM P°int processor 37 positions the cursor in 

23 response to the mouse "point and click" operations. 
-4 Using the AIM-supplied pointing.- rules, the AIM point 

25 processor is able to interact with the host application, 

26 independent of the AIM'S involvement, to c-.use the host 

27 to reposition the cursor. AIM menu selection processor 36 

2 8 perforins the operations defined for a given menu selection. 

29 The operation may either be local, i.e., may cause an 

30 act i°n within the workstation, or may direct the host 

31 application to perform varicus operations. 

32 

33 Central event/time monitor 10, in response to a set 

34 °* primitive mouse events, passes the events to decoder 40. 

35 Monitor 10 is also responsible for determining and setting 
35 the priority for the distribution of the nouse-generated 
37 events. AIM control table 28 contains the data structures 
5S required to switch data and operations arr.ongst the AIKs. 
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1 Mouse event decoder 40, in response to the set of 

primitive mouse events from monitor 10, creates a universal 

3 set of mouse-generated events and passes the data to the 

4 applicable processor (i.e., region selector, scroll 

5 processor, AIM point processor or AIM menu selection 
5 processor). Decoder 40 generates a different set of 

7 these universal events for each of the four operations to 

8 be processed by one of the four mouse-event processors: 

9 movement, points, scrolls and menu selections. 

10 

2 j. Region selection: When a "mouse down 11 event, outside 

2 2 the area occupied by the menu bar or a scroll 

13 bar, is followed by a "mouse still down" event. 

14 in another location, decoder 40 passes the 

15 beginning coordinates to the region selector 42 
15 and enters a passthrough state. Until a "mouse 
17 up" event is received, the "mouse still down" 

events are passed through decoder 40 to region 
selector 42 . When the "mouseup" event is 
2Q passed to the region selector, decoder 40 

21 reenters its decoding state. 



19 



22 
23 
24 
25 
26 
27 
28 
29 

21 
32 
33 
34 
35 
36 



Scrolling: When a "mouse down" event inside the ares 
occupied by a scroll bar is followed by a 
"mouse still down" event in another location, 
decoder 40 passes the beginning screen coordi- 
nates to scroll processor 45 and enters a 
passthrough state. Until a "mouse up" event is 
received the "mouse still down" events are 
passed through the decoder to the scroll pro- 
cessor. When the "mouse up" event is passed to 
the scroll processor, the decccer reer.ters its 
decoding state. 

Feinting: When a "mouse down" . event inside the area 
occupied by a window is optionally followed by 
a set of "mouse still down" events, then by a 



I 
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1 
2 



"-use up" event in the same location, decode c 0 
passes the screen coordinates to AIM po *-t 
3 processor 37. 

4 

5 AIM menu selection: When a "mouse down" event ir.ci^ 

6 the area 0 ^upied by the menu bar is .foiled" 

7 by a set of "mouse still down" events in another 

8 location, then by a "mouse up" event which" ~ 

9 signifies a valid menu selection, decode- 
10 ' P£sses the me ™ and item numbers to AIM menu 
!l selection processor 36. 

12 

13 _ The virtual mouse event input port 48 proved- a - 

14 internal interface point where other parts of the sv-J-, 

15 (e.g., the "learn function" when operating in "pl=vtack 

16 moae") may inject mouse operation events. Air, ^ Ru 

17 selection processor 36 performs, for the menu itea se^-W 

18 the set of operations defined by the AIM menu sel-cti- 
2S processing rules (i.e., what to do when a menu item a T 

20 selected). AIM menu selection processing rules (c h , v . 

21 schematically at 49 in Fig. 7) provide the procr«Jna 

22 xor the processing to be performed as a result of r «*n" 

23 selections. AIM point processor 37, based upon t^ M „ 

24 pointing rules (i.e., cursor movement rules), directs Y»>e 

25 host application to position the cursor to the "no^n— 

26 to" location. The AIM pointing rules £1 provide Yh-" 

27 programming for the pointing operations. 
28 

29 Scroll processor 45 causes data in buffer 27 to 

30 scroll. When the scroll operation crosses the b--^---p. 

31 of the current contents of the buffer, the scroll 7~c^-=c- 

32 based upon the scrolling rules 52 supplied by the aim" 

33 directs the host application to scroll buffer 19. when 

34 the scroll processor receives the "r.ouse uo" eve-t <t 

35 updates a data structure which indicates the coordinate- ' 

36 of the Currently-displayed screen. 
37 



c 
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1 The Mil-supplied scroll ina rules 52 provide the 

2 programming for the strolling operations. The AIM supplies 

3 'the instruction table which the scroll processor uses to 

4 "look up" the instructions: which it must send to the host 

5 application to cause it to perform scrolling operations 

6 which are outside the contents of the current buffer 19. 

7 Region selector 42 updates buffer 27 to indicate which 

8 area of the screen is being selected by the inouse opera- 
tion. Vhen the region selector receives the- "mouse up" 
event, it updates a data structure which indicates the 

11 coordinates of the currently-selected regions. When a 

12 region selection cresses the boundaries of buffer 19, the 

13 region selector r.ay call the scroll processor to cause 

14 the data in buffer 27 to scroll. 
15 

16 AIM Initialization 

The AIM initialization subsystem (Fig. 8) consists 
only of the AIM initialization processor 56 and performs 
the functions required to get an AIM started. When an 
AIM is launched, event/time monitor 10 activates the AIM 
initialization processor 56 which sets the beginning 
environment for the AIM. Central event/tise monitor 10, 
when control is added for an additional AIM by way of the 
AIM control table 28, calls the AIM initialization crocesso 



17 
18 
* a 



21 
22 
23 
24 
25 
26 
27 
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29 
33 
31 
32 
33 



AIM control table 2£ contains the data structures 
required to switch data and operations among the AIMS. 
AIM initialization processor 56 is the portion of the AIM 
which performs the initialization operations required by 
the AIM. The AIM initiali z aticn processor follows the 
prcgrarr, provided by the sequence and execution tables 
within the AIM initialization rules 57 (see Fig. IC-rule 
processing detail), to perfcra its functions. AIM initiali 
2 aticn rules 57 provide the programing for the initializa- 



35 ticn operations, 



36 
37 
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1 AIM Signal Processing 

2 The AIM signal processing subsystem (Fig. 9) consists 

3 only of AIM signal processor 58 and performs the functions 

4 required to respond to various stimuli defined as signals 

5 (e.g., events such as create a window or messages such as 

6 physical host connection lost, etc). When such events 

7 are received, central event/time monitor 10 activates 

8 signal processor 58. 
S 

10 AIM signal processor 58 is the portion of the A I H 

11 which performs the operations required to respond to the 

12 'signals received. The AIM signal processor follows the 

13 Program provided by the sequence and execution tables 

14 within the AIM signal processing rules 57 to perform its 
25 functions. 

16 

17 Virtual Terminal and Virtual Window Buffer Detail 



18 Virtual terminal buffer 19 contains four major 
29 structures: 

20 Displayable characters: 

21 The displayable characters are represented in 

22 ASCII format. The position of the characters 

23 is represented by their position in a data 

24 structure within buffer 19. 
25 

25 Display attributes: 

27 The display attributes, related to the display 

28 as would be presented on the host's terminal 

29 being eirjlated, are represented in a data 

30 structure within buffer 19. All attributes 

31 which apply to a set of characters, such as set 

32 beginning/end cf field type, are representee by 

33 a sil >gle entry for each cf the individual 

34 characters affected. All attributes, such as 

35 display ir.tensity/cclor , character set, etc., 

36 are "Presented in this manner. The content 
37 
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1 and form of the data structure which contains 

2 the representation of the display attributes is 

3 dynamic in definition. That is, the meaning/use 

4 of the fields within the data structure is 

5 defined by the input terminal emulation rules. 
t 

6 

7 Virtual window mapping: 

8 The corresponding position, if any, of a terminal 
buffer 19 character within the window buffer 27 
is maintained. That is # every displayable 

1X character in the buffer 19 has a corresponding 

12 pointer which indicates whether or not it is 

13 contained within the window buffer and, if so, 

14 where it is located within the window buffer. 

15 

16 Portions of the virtual window mapping may be 

17 defined as active by the AIM. Active mapping 
le areas provide the ability to cause screen 

information from a particular area within the 
terminal buffer 19 to be automatically placed 
in the window buffer in a specified position, 
with the attributes set up in the window buffer. 
This function can be performed by the terminal 
emulator 17a without further interaction from 
the AIM. 
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Most recent character changes: 

Since certain terminal command sequences change 
sets of characters, a data structure is main- 
tained to koep track of the lines which contain 
changes. 

Virtual window buffer 27 contains four major struc- 
tures. The structures for displayable characters, display 
attributes and virtual mapping are essentially the same 
as those described above for the structures cf -virtual 
terminal buffer 19. 
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1 Window buffer 27 also contains the following struc- 

2 tures. 

3 Most recent region changes: 

4 Since the update of the workstation screen is 

5 performed on the basis of time, a data structure 

6 is maintained to keep track of the regions which 

7 contain changes since the previous update. 
8 

9 Rule Processing Detail 
10 

11 The various rule processors (Fig. 10) form the back- 



12 bone of the AIMs. The rule processor is a translator 

13 which accepts stimuli (i.e., the input sequence), parses 

14 the stimuli, then executes a specified set of functions 

15 as a result of the stimuli. In essence, the rule processor 

16 is a set of state machines driven by the input sequence 61 

17 and various states. In this use, a state is syrionynscys 

18 with a condition or a status. 
19 

20 Logically, there ere two such state machines, the 

21 sequence recognizer 62 and the rule executor 63. The 

22 commands are determined by the type of stir.uli and speci- 

23 fied by the sequence table 64. The capabilities of the 

24 "lancuage" represented by the state machine are determined 

25 by the execution table 66. Generally, the functions 

26 which are executed as a result of this process ere 

27 routines with a high level of functionality with respect 

28 to the workstation's tasks. 

29 '• 

30 Sequence recognizer 62 is the language parser portion 

31 of the translator. The input sequence 61 is parsed by 

32 matching against sequence table's 64 entries, including 

33 the recognizer state 67. When . a match is found, the 

34 sequence table entry points to a specific rule within the 

35 execution table 66. Ccntr'el is then passed to the rule 

36 executor 63. 
37 

"8 " 
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1 Sequence table 64 contains the parsing sequences 

2 which the rule processor recognizes as commands. In this 

3 respect, the sequence table defines the language under- 

4 stood by the rule processor. In addition to the command 

5 sequence definition, the sequence table also points to 

6 the associated function set to be executed as a result of 

7 that command. The sequence table has the structure shown 

8 in Fig. 11. 

c 

10 Condition name: 

11 The meanings of the terms used in the example of 

12 Fig. 11 are as follows, assuming that the example is 

13 for AIM menu selection processing for a word process- 

14 ing/editor interface which has a pull-down menu. 

15 Fig. 11 also assumes that changing the mode setting 

16 changes the menu entry to allow a user to change to 

17 the other mode and that when exiting the insert 

18 mode, the current line of text must be justified if 

19 that portion of text is set to be justified. 

10 

21 The condition name provides a user-oriented name for 

22 the sequence recognizer line entry. The line entry 

23 defines the recognizable state which leads to the 

24 selection of the rule set to be executed. 
25 

25 * Set of states: 

27 The fields which make up the set of states (to be 

28 recognized) are dynamically defined during the 
oo scecification cf the secuer.ce tahle. These fields 
32 include both local and ether states. 

31 

32 Input sequence: 

33 The input sequence is the multi-byte input to the 

34 recognizer; fcr example, the arriving characters in. 

35 the case cf the terminal emulator. The input sequence 

36 is parsed based upon the current values of the set 

37 of states specified. The result is the identification 
28 • of the rule set to be executed. 
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1 Rule set name: 

2 The rule set name , provides a user-oriented name for 

3 the set of rules to be executed. 
4 

5 Recognizer State: 

6. The recognizer state contains the current, local 

7 status information for the sequence recoonizer. Local 

8 states may be defined during the specification of the 

9 execution table. 

10. 

11 Rule Executor: 

12 The rule executor performs the command ev e ~ u *ion 

13 functions within the translator. The rule executor has 

14 the constructs to perform the flow control operations 

15 which are equivalent to the more traditional gresanars 

16 specified as "continue", "goto", "break", "exit", 

17 "if--.. then.... else....", "for. . . .do. . . . done ' ' and 

18 "while.... do done". The rule executor also resolves 

:9 symbolic references contained in the rule line entry. 

20 The symbolic references may come from the input sequence 

21 or from the execution table. When the references "have" 

22 been resolved, the rule executor passes control to the 

23 functions to be executed. 
24 

25 ' Execution table: 

26 The execution table shown in Fig. 12 contains the 

27 sets of entries which the rule executor interprets to" 

28 perform the cc.-T.ands indicated in the sequence table, in. 

29 this respect, the execution table defines the cac&bili-*" 
20 ties of the rule processor. The terr.s in the execution 
31 table have the following meanings: 

32 

-3 Rule name: 

34 The rule name provides a user-oriented name for the. 

35 set of rules to be executed. 
36 

37 
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Set of states: 

The fields which make up the set of states to be 
recognized are dynamically defined during the speci- 
ficaton of the rules. These fields include both 
local and other states. 

Function: 

The function is the name of the function to be 
executed. Ultimately, it must be a name which can 
be resolved to a known C-code function. Externally, 
it may be mapped, through the use of the developer 
tools and tables, to a more human-useable form. 

Parameters : 

The parameters are the parameters to be passed to 
the function being executed". Parameters which are 
symbolic names must be resolved to the C-code level. 
Externally/ they may be mapped, through the use of 
the developer tools and tables, to a more user-oriented 
form- 

(Sets of:) new states: 

The new states are the settings for the local states . 
These states may be in addition to the states main- 
tained by the functions themselves. This allows the 
AIM specifier to create states as required to indicate 
the state of the host application (e.g., Kode: 
Insert or Overtype). The fields which make up the 
set of states to be recognized are dynamically 
defined during the specification of the rules. 

ets cf : ) next rule: 

The next rule is the nar.e of the next rule to be 
executed. The lack of an entry indicates the next . 
sequential rule entry. The next rule may also 
indicate a rule set as a subroutine. 
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* Executor state: 

2 . , The executor state 68 contains the current, local 

3 status information for the rule executor. 

5 Although the sequence and execution tables are 

6 explained as two separate units, that particular division 

7 is used only as a model. The actual implementation may 

8 ranee from a single-table version for a simple rule 

9 processor which- uses a linear interpretation scheme to a 
version which uses different tables and corresponding 

11 state machines for such elements as the input sequence 

12 parsing, the current state parsing) the actual function 

13 execution, etc. 
14 

15 Technology . 

Although the workstation concept described herein is 
17 based upon common, commercially-available hardware tech- 
nology, it is the price-performance ratio of this proven 
hardware technology in combination with some of the r.-ost 

20 recent software technology in the user-interface area 

21 which makes the described workstation a practical invention 

22 today. However, since it is obvious that neither the 

23 hardware nor the software technology will stagnate, the 

24 invention, from its concept to its architecture and 
engineering, is designed to embrace ir.proved hardware and 
software technologies. As the cost per unit of perf cr-nance 

27 of the hardware continues to decline and as new or ir.proved 

28 user-interface software beeches commercially practical, 

29 the described invention will be able to incorporate these 

30 concepts without changing its basic concept or even its 

31 basic architecture. 
32 

33 There have been two major developments in the hardware 

34 technology which make the invention described above 

35 commercially viable. The first was the development 0 f 
36 

37 
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1 physically small, inexpensive computers based upon micro- 

2 processors in the class usually referred to as "super- 

3 micros". The second development was the commercial 

4 production of the first type of computers with companion 

5 printers which have graphic capabilities with enough 

6 resolution to present the type of display screen and 

7 printed material required by the "iconic" , graphics-based 

8 types of presentation used by the present user-interface 

9 software and hardware technology. 
10 

11 An early implementation of the invention involved 

12 the use of the : technologies mentioned above in an unmodi- 

13 fied form. That is, the workstation software used existing 

14 microprocessors along with the existing Read-only Memory 

15 (ROM), semiconductor Random Access Memory (RAM) and 

16 external mass storage in the form of disks, both low- 

17 capacity, flexible disks and medium-capacity, hard disks. 
18 

1? Various hardware trends apparent today will make the 

20 described invention easier to implement in the future. 

21 Various implementations such as Commodore's Amiga computer 

22 are making extensive use of dedicated hardware modules to 

23 support the graphics functions required. This approach 

24 will greatly improve the price-performance ratio of the 

25 hardware. Future generations of the present workstation 

26 may use various combinations of ROM, alternative RAM 

27 technology, alternative disk technology and/or alternative 

28 microprocessor technology. 
29 

30 For example, it would be natural to supply various 

31 versions of the workstation with the run-time system 

32 contained in ROM . Similarily, it would be practical to 

33 cevelcp certain !, f ixed-product" workstations for use as 

34 specific monitors in areas such as process control, which- 

35 contained even the AIM in ROM. In general, the only 

36 portions of the architecture which are not implementable 

37 in ROM are the dynaxic data structures. 
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Many of the portions of the architecture could also 
be implemented using combinatorial, sequential and/or 
microcoded, processor-based logic. Modules such as the 
direct, native environment interfaces vould be prime 
candidates for this approach. In the area of micropro- 
cessors, developments such as Intel's "transputter" 
technology may be used to provide separate computers for 
the various asynchronous units within the present 
9 architecture. 



There has been one major development in the software 
technology which makes the workstation concept attractive; 
the development of, and industry acceptance of, the 
various approaches to the windowed, iconic, graphics- 
oriented user-interface presentations, available as 
mass-produced, inexpensive software development tools for 
the "super micros" mentioned above. 

18 
19 
20 

21 
22 

23 
24 
25 
26 

2 ? 
28 

The present workstation software can be i-plerr.er.ted 

29 on any co.-nputer which crevices the computing and* graphics 

30 cepecility required to present a windowed, iconic' grachical 

31 style of user interface. In practical ternss, ccnraercial " 

32 versions ere r.ost readily produced utilizing computers 

33 which provide the tools, to expedite development.* Such 

34 computers available today are the Apple Macintosh and the 
.35 IBM pc/XT/AT with the Microsoft Windows environment. 

36 Other possibilities available today are the Atari 520ST 

37 computer and the Ccmmodcre Arnica comets ter 

38 • . * 



One embodiment of the present invention utilises an 
Apple Macintosh computer to provide a multisession, 
terminal emulator with the majority of the features 
specified for the IBM 3270 terminal. The product, in 
combination with Tri Data Corporation's Netway lOCCa 
communication protocol converter, interfaces to IE:-] 
computers via Bisynchronous (ESC) or Systems Network 
Architecture (SKA)/Synchronous Data Link Control (SDLC). 
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1 The windowed, iconic, graphical style of user inter- 

2 face commercialized by the Xerox Star product and exeaplz- 

3 fied by the Apple Macintosh is generally considered the 

4 b «t user interface technology available today. In that 

5 respect, the present workstation retains the presentation 

6 of the user interface as provided for by the Native 

7 Environment upon which it is based (e.g., the Apple 

8 Kacintosh or the IBM PC/XT/AT). However, it should be 

9 noted that the current architecture embraces new and/or 

10 completely different presentations of user interface 

11 t^chnolocies as they become available. For example, with 

12 the commercial viability of speech recognition and accurate, 

13 intelligible voice systhesis, compatible AIHs for these 

14 products can be implemented. 

W in oeneral. any new user interface technology may be 

17 added to' the architecture of the present invention. 

18 Technclocies which deal with output to the workstation 

19 user are'interfaced through a module which translates uhe 

20 ■ host's presentation (via the host's screen) to the new 

21 presentation format for the user. Technologies which 

22 deal with inout from the: user are interfaced througn a 

23 ...odule which translates what the user does es input, 
2L relative to what the user interacts with (e.g., t..e 

25 workstation's screen), to what the host understands as 

26 valid input from the terminal it thinks it is correcting 

27 with. 
28 

29 Attached hereto as Appendix A are copies. cf computer 

30 proararr.s written in C coce showing n ..pi e.. 

, • . n ^ r i»^'cq the lollovmg: 

31 present invention. Appendix A mcL-s «~ie -° * 

30 i. central event monitor 10, parts 1, 2 and 3, 

33 2 -ITOS (Operating system Desk Top Initiator); 

34 3'. FITOS (Operating System Tool Box Functions; • 

35 4 Host interface Routines For Serial Asynch 



36 multichannel; 
37 
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AIM Initialization Routine; 

Emulation of H(Keathkit)19 terminal as an 

AIM— Virtual Terminal Support Module; 

AIM— virtual Terminal Library; 

AIK— Graphic Window for Hultiplan AIM. 



0237671 



CLAIMS 

1. A system for executing a computer application 
program in a host computer (11) under the control of a 
second computer located at a workstation and including 

5 a display screen (13), characterised by: 

means for translating selected portions of the 
host computer's presentation information into 
functionally equivalent user-oriented presentation 
information for use in the second computer; and 
10 means for translating a user's responses to the 

user-oriented presentation information at the second 
computer into response information for use in the host 
computer to interact with the application program. 

2. A system as claimed in claim 1 characterised 
15 by an input terminal emulator (17a) which emulates a 

terminal at the workstation, means for supplying the 
host computer's presentation information to the 
terminal emulator, and means for utilizing the output 
of the terminal emulator to produce the functionally 
20 equivalent user-oriented presentation information. 

3. A system as claimed in claim 2 characterised 
by means for supplying at least some of the output of 
the input terminal emulator (17a) to a virtual terminal 
buffer (19) for buffering of the at least some of the 

25 terminal emulator output. 

4. A system as claimed in claim 3 characterised 
by means for processing selected outputs of the 
terminal emulator (17a) and the virtual terminal buffer 
(19) in an application interface module (21), the 

30 module processor processing its inputs in accordance 
with characteristics of the application program to be 
executed in the host computer (11). 

5. A system as claimed in claim 4 characterised 
by means for supplying the product of the application 

35 
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interface module processor (21) to a virtual window 
manager (26) for controlling the display screen (13). 

6. A system as claimed in claim 3 characterised 
by means for supplying at least some of the output of 
the terminal emulator (17a) to a virtual window buffer 
(27) to buffer information to be displayed on the 
display screen (13). 

7o A system for executing a computer application 
program in a host computer (11) under the control of a 
secondary computer having a display screen (43) and a 
user-friendly interface, characterised by: 

a communication function module (16) connected to 
the host computer, the communication function module 
receiving information from the host computer and 
transmitting information from the second computer to 
the host computer; 

an input terminal emulator (17) connected to the 
communication function module for translating 
information received by the communication function 
module from the host computer into functionally 
equivalent user-oriented presentation information for 
use in the second computer; 

a virtual window buffer (27) for receiving 
information from the input terminal emulator; and 

means responsive to information from the virtual 
window buffer for controlling the display screen in 
response to execution of the application program in the 
host computer. 

8. A method of executing a computer application 
program in a host computer (11) under the control of a 
second computer located at a workstation and including 
a display screen (13), characterised by the steps of; 

_ translating selected portions of the. host 
computer's presentation information into functionally 
equivalent user-oriented presentation information 
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for use in the second computer; and 

translating a user's responses to the user- 
oriented presentation information at the second 
computer into response information for use in the host 
computer to interact with the application program. 

9. A method as claimed in claim 8 characterised 
by the steps of supplying the host computer's 
presentation information to an input terminal emulator 
(17a) which emulates e terminal at the workstation, and 
utilizing the output of the input terminal emulator to 
produce the functionally equivalent user-oriented 
presentation information. 

10. A method as claimed in claim 9 characterised 
by the step of supplying at least some of the output of 
the input terminal emulator (17a) to a virtual terminal 
buffer (19) for buffering of said at least some of the 
terminal emulator output. 

11. A method as claimed in claim 10 characterised 
by the steps of processing selected outputs of the 
input terminal emulator (17a) and the virtual terminal 
buffer (19) in an application interface module 
processor (21), the module processor processing its 
inputs in accordance with characteristics of the 
application program to be executed in the host 
computer o 

12. A method as claimed in claim 11 characterised 
by the step of supplying the output product of the 
application interface! module to a virtual window 
manager (26) for controlling the display screen (13). 

13. A method as claimed in claim 10 characterised 
by the step of supplying at least some of the output 
product of the terminal emulator (17a) to a virtual 
window buffer (27) for buffering information to be 
displayed on the display screen (13). 
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14. A method as claimed in claim 12 characterised 
by the step of supplying at least part of the output 
product of the window manager (26) to a virtual window 
buffer (27) for buffering information to be displayed 
on the screen. 

15. A method as claimed in claim 14 characterised 
by the step of supplying at least part of the output of 
the terminal emulator (17a) to the virtual window 
buffer (27 J. 

16. A method as claimed in any preceding claim 
characterised in that the workstation comprises a 
keyboard (12), and in that the translation of a user's 
responses includes transmitting information from the 
keyboard at the workstation to the host computer (11). 

17. A method as claimed in claim 17 characterised 
by the steps of j 

supplying the information from said keyboard (12) 
to an output terminal emulator (17b) which emulates a 
terminal at the host computer 1 1 ; and 

utilizing the output of the output terminal 
emulator to produce the response information for use in 
the host computer. 

18. A method as claimed in claim 17 characterised 
by the step of supplying the output of the output 
terminal emulator (17b) to a first-in first-out buffer 
(36) for buffering the output terminal emulator output. 

19. A method as claimed in any one of claims 1 to 
16 characterised in that the workstation comprises a 
mouse (12), and in that the translation of a user's 
responses includes transmitting information relative to 
movement of the mouse at the workstation to the host 
computer (11). 

20. A method as claimed in claim 19 characterised 
by the steps ofs 

supplying the information relative to movement 
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of the mouse to an output terminal emulator (17b) which 
emulates a terminal at the host computer (11); and 

utilizing the output of the output terminal 
emulator to produce the response information for use in 
the host computer* 

21, A method as claimed in claim 20 characterised 
by the step of supplying the output of the output 
terminal emulator (17b) to a first in — first out buffer 
(30) for buffering the output terminal emulator output, 

22. A method of executing a computer application 
program in a host computer (11) under the control of a 
second computer having a user-friendly interface, 
characterised by the steps of: 

generating a plurality of application interface 
aodule programs for a plurality of the application 
programs, each of the application interface module 
programs being arranged to be executed in the second 
computer to cause execution of the corresponding one of 
the application programs in the host computer; 

transmitting a selected one of said application 
interface module's programs to the second computer; 
and 1: 

executing the selected one of the application 
interface module programs in the second computer using 
the user-friendly interface to produce execution of the 
application program in said host computer. 

23o A method as claimed in claim 22 characterised 
by the steps of storing a plurality of the application 
interface module programs in the host computer, 

24, A method of developing an application 
interface module for controlling the program in a host 
computer (11) under the control of a second computer 
located at a workstation, characterised by the steps 
of: 
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editing rule tables relating to application- 
specific interface operations for controlling the 
translation of selected portions of the host computer's 
presentation information into functionally equivalent 
user-oriented presentation information for use in the 
second computer and for controlling the translation of 
a user's responses to the user-oriented presentation 
information at the second computer into response 
information for use in the host computer to interact 
with the application program. 
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Dear Sirs 

Applicationg*S~308 395.2 
Mi tern Development Partners 
Our Ref M-356 

1 refer to the invitation to rememedy deficiencies dated 

18 December 1986 the term for response to which was extended 

by the communication dated 4 March 1987 until 18 May 1987. 

It has now been decided that the best course would be to 
cancel Appendix A from the application, and, cancelation, of 
Appendix A is accordingly hereby now requested. 



It is understood that formal drawings have now been received 
and are acceptable, so the present request for cancellation 
deals satisfactorily with all the formal deficiencies to 
which objection was taken. 

Yours faithfully 
P0LLAK MERCER 4 TENCH 
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Figure 2 
System Information Flow 
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Figure 3 
Input Stream Processing 
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Display Processing 
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Figure 6 
Keystroke Processing 
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Mouse Operation Processing 
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RIM Initialization 
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Figure 9 
RIM Signal Processing 
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